home *** CD-ROM | disk | FTP | other *** search
/ Meeting Pearls 1 / Meeting Pearls Vol 1 (1994).iso / installed_progs / text / faqs / mail.archive-servers < prev    next >
Encoding:
Internet Message Format  |  1994-02-17  |  29.6 KB
  1. Subject: Mail Archive Server software list
  2. Newsgroups: comp.mail.misc,comp.sources.wanted,comp.answers,news.answers
  3. From: serini@ghost.dsi.unimi.it (Piero Serini)
  4. Date: 16 Feb 1994 04:12:32 +0100
  5.  
  6. Archive-name: mail/archive-servers
  7. Last-modified: 1994/02/15
  8. Version: 2.0
  9.  
  10.  
  11.                       Mail Archive Server Software List
  12.          A Summary of Available Mail Archive Server Software
  13.              ---------------------------------------------------
  14.  
  15.                             by:  Piero Serini
  16.                       piero@strider.st.dsi.unimi.it
  17.                         serini@ghost.dsi.unimi.it
  18.  
  19.         Last Update: Tue Feb 15 19:42:58 MET 1994
  20.                         This FAQ's version:  2.0
  21.         (C) Jonathan I. Kamens 1991,1992,1993 - All Rights Reserved
  22.                (C) Piero Serini 1994 - All Rights Reserved
  23.  
  24.   Mail Archive Servers are programs  which  receive incoming  mail messages,
  25. interpret them, and take action based on them.  For example, two tasks which
  26. might  be  performed  by mail servers are handling  subscriptions to mailing
  27. lists and redistributing messages sent to the lists; and delivering files to
  28. users based on incoming requests.
  29.  
  30.   This posting focuses, primarily, on mail servers which run under UNIX. For
  31. each server listed below, I provide the following information, if known:
  32.  
  33.         Name
  34.         Author
  35.         Maintainer
  36.         Latest known version
  37.         How to get it
  38.         Implementation language
  39.         Supported platforms
  40.         Comments
  41.  
  42.   If you can fill any of the blanks or have  comments about anything written
  43. below, or if you have new servers to add to the list, please let me know. If
  44. you would like to ask me to change  this  posting in some way,  the method I
  45. appreciate most is for you to actually make  the desired  modifications to a
  46. copy of the posting, and then to send me the modified part or a context diff
  47. between my posted version and your modified version.   Submitting changes in
  48. this way makes dealing with them easier for me and helps to avoid  misunder-
  49. standings about what you are suggesting.
  50. Please send all updates to MAS-FAQ@strider.st.dsi.unimi.it
  51.  
  52.  
  53. 0.0     Organization and availability
  54.  
  55.     This FAQ is posted monthly, the 15th, on comp.mail.misc,
  56.     comp.sources.wanted, comp.answers and news.answers.
  57.  
  58.     It is available:
  59.     - from the above USENET groups
  60.     - from all the USENET archives
  61.     - ftp//ghost.dsi.unimi.it[149.132.2.1]:~ftp/pub/FAQs/MAS.Z
  62.  
  63.     Note: the ftp directory will be set up shortly.  I haven't root per-
  64.           missions on ghost.   If ~ftp/pub/FAQs doesn't exist, try again
  65.           in a day or two. Thank you.
  66.  
  67.     A context diff file  containing the differences between this FAQ and
  68.     the previous release is posted on comp.mail.misc,comp.sources.wanted
  69.     and is available from the same sites in the file:
  70.     ~ftp/pub/FAQs/MAS.diffs.Z.
  71.  
  72.     This FAQ is NOT reposted if modified, until the next issue date.
  73.     I  will  modify  the ftp file only.  I  suggest using ftp to get the
  74.     latest version of this document.
  75.  
  76.         This FAQ consists of four parts:
  77.         0.*     Organization.
  78.         (0.1    Copyright)
  79.         (0.2    Warranty)
  80.         (0.3    Publishing Notes)
  81.         1.*     Software List.
  82.         2.*     Archivers, what they archive, how to download.
  83.         3.*     History and Contributors' list.
  84.  
  85. 0.1    Copyright
  86.  
  87.     This FAQ is Copyright (C) 1993, 1994 by Piero Serini.
  88.     All Rights are reserved.
  89.     Permission  to use,  copy and distribute this FAQ, or parts thereof,
  90.     by any means and for any purpose  EXCEPT  PROFIT PURPOSES  is hereby
  91.     granted,  provided that both  the above  Copyright notice  and  this
  92.     permission notice appear in all copies of the FAQ itself.
  93.     Reproducing  this FAQ or parts thereof  by any means,  included, but
  94.     not limited to,  printing,  copying existing prints,  publishing  by
  95.     electronic  or other  means,  implies  full  agreement  to the above
  96.     non-profit-use clause, unless upon explicit prior written permission
  97.     of the author.
  98.  
  99. 0.2    Warranty
  100.  
  101.     THIS  FAQ  IS PROVIDED BY THE  AUTHOR ``AS IS'',  AND ANY EXPRESS OR
  102.     IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,  THE IMPLIED WAR-
  103.     RANTIES OF MERCHANTABILITY AND FITNESS  FOR A PARTICULAR PURPOSE ARE
  104.     DISCLAIMED.
  105.     IN NO EVENT SHALL  THE  AUTHOR  BE LIABLE FOR  ANY DIRECT, INDIRECT,
  106.     INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
  107.     BUT  NOT LIMITED  TO, PROCUREMENT OF SUBSTITUTE GOODS  OR  SERVICES;
  108.     LOSS OF USE,  DATA,  OR PROFITS;  OR BUSINESS INTERRUPTION)  HOWEVER
  109.     CAUSED AND ON ANY THEORY OF LIABILITY,  WHETHER IN CONTRACT,  STRICT
  110.     LIABILITY,  OR TORT  (INCLUDING NEGLIGENCE OR OTHERWISE)  ARISING IN
  111.     ANY WAY OUT OF THE USE OF THE INFORMATIONS HEREIN CONTAINED, EVEN IF
  112.     ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
  113.  
  114. 0.3    Publishing Notes
  115.  
  116.     If  you  want to publish  this FAQ  by any means,  electronically or
  117.     otherwise, you can do it, provided the following conditions are met:
  118.     1) The above Copyright notice and Warranty  appear in their entirety
  119.        in all copies you publish;
  120.     2) You notify me by e-mail that you will publish this FAQ;
  121.     3) You use the latest version of the FAQ you can get;
  122.     4) You let people know where to find updated versions of the FAQ;
  123.     5) Any modifications (other than typesetting changes) you make to it
  124.        are clearly designated as your modifications;
  125.  
  126.     You  shall  also  send me a copy of the  published  material, in its
  127.     entirety, free of charge.  Should this not be possible, due to legal
  128.     or other restrictions,  please send me the part containing this FAQ,
  129.     with  full references  to the published material  (i.e. ISDN or any-
  130.     thing else to identify it), free of charge.
  131.  
  132.  
  133. 1.0    Software List
  134.  
  135. Name:        Almanac
  136. Author:        Erik Bennett
  137. Author:        Chris Hansen
  138. Maintainer:    almanac-admin@oes.orst.edu
  139. Implementation language: C (configured with Bourne shell)
  140. How to get it:    ftp oes.orst.edu:~ftp/pub/almanac-x.x.tar.Z
  141.             (where x.x is the current version)
  142. Latest version:    1.5
  143. Supported platforms: SunOS, HP/UX, UTek, AIX (RS 6000), most BSD 4.3
  144. Comments:    (Chris Hansen <hansenc@oes.orst.edu>)
  145.     - Requires sendmail and gdbm
  146.     - Can split files on user-defined size limit
  147.     - Good user & admin documentation
  148.     - Has blacklist
  149.     - Logging (through syslog) and usage utilities
  150.     - Comes with supplement for automatic mailing list management
  151.     - Load checking or queuing left to sendmail
  152.     - Main advantage is configuration table:
  153.         Maps user commands to shell commands
  154.         Can have any number of user commands
  155.         Encoding, Filtering, Compression all configurable
  156.     - Most other things configurable
  157.     - Possible disadvantages:
  158.         Table can get complicated.
  159.         Good knowledge of shell advised).
  160.  
  161. Name:        B-Server
  162. Author:        Budi Rahardjo <rahardj@ccu.umanitoba.ca>
  163. Implementation language: bourne shell
  164. How to get it:    Get "b-server.shar" from grasp1.
  165. Comments:    (Dave Shaver <shaver@convex.com>):
  166.     - Don't need to create system-wide alias (uses sendmail
  167.       .forward file)
  168.     - One shell script
  169.     - Can refuse to provide service to certain people
  170.     - Has file and request limits
  171.     - 4 user commands: help, index, send, get
  172.  
  173. Comments:    (john.Latala@Waterloo.NCR.COM):
  174.     - Only does text files
  175.  
  176. Name:        Bart (Brode's Archive Retrieval Thang)
  177. Author:        Jon Brode <brode@icpsr.umich.edu>
  178. Latest known version: beta release
  179. How to get it:    Send E-mail to <brode@icpsr.umich.edu> and ask for it.
  180. Implementation Language: C
  181. Support platforms: Expects BSD, sendmail and ndbm, but might work with
  182.                     some tweaking in other environments.
  183. Comments:    (from the author)
  184.     - Beta release can be obtained from the author but should not
  185.       be redistributed; the final release will have more lenient
  186.       distribution conditions.
  187.     - Runs from alias or .forward file
  188.     - Very careful about not overloading server.
  189.       (does load checking on BSD machines, in addition to the
  190.       other things)
  191.     - 5 commands: help, index, path, send, sendb
  192.       "sendb" automatically encodes the file, "send" determines
  193.       whether the file needs to be encoded first
  194.     - Can request files by parts. Useful for requesting files
  195.       larger than quota and retrieving pieces that get lost in
  196.       the mail
  197.     - Can do per-user quota checking.
  198.     - It has a man page!
  199.     - Has uuencode encoding built into C code, does not support
  200.       other encoding types yet.
  201.     - No user error notification on bad requests.
  202.  
  203. Name:        Clarkson
  204. Author:        Michael DeCorte
  205. How to get it:    Get "archive-server" from CLARKSON.
  206. Implementation language: bourne shell, awk
  207. Comments:    (Tom Fitzgerald <fitz@wang.com>)
  208.     Advantages:
  209.       - Most flexible options for archiving, compressing, encoding
  210.         and slicing result.
  211.       - Very nice load-limiting.
  212.     Disadvantages:
  213.       - Many BSDism's (I tried porting it to SysV without much luck).
  214.       - Can't return several requested items, one item per mail
  215.         message.
  216.       - It insists on packaging up all requests into a single
  217.         archive, splitting the archive at random points and mailing
  218.         the result.
  219.       - Can't store items compressed and have them mailed back to
  220.         the requestor decompressed.
  221.  
  222. Name:        DECWRL
  223. Author:        Brian Reid.
  224. Implementation language: bourne shell, awk, a little bit of C
  225. How to get it:    - Get "decwrl.shar" from grasp1.
  226.         - ftp.cs.widener.edu:/pub/src/mail/archive.tar.Z
  227.           (slightly modified).
  228. Comments:    (Dave Shaver <shaver@convex.com>)
  229.     - Written with many shell scripts and a few AWK scripts
  230.     - Very careful about not overloading server machine
  231.       (Remember, this used to run on an over-worked VAX.)
  232.     - Very easy to install; best of the group?
  233.     - Code is all quite generic
  234.     - Good at letting person making request know what happened
  235.       (No black holes for mail.)
  236.     - Good user-level docs (especially the "help" file)
  237.     - Very fair queuing system; people can't make "pigs" of
  238.       themselves
  239.     - 4 user commands: help, index, send, path
  240. Comments:    (Tom Fitzgerald <fitz@wang.com>)
  241.     Advantages:
  242.       - Simplest.
  243.       - Very nice load-limiting, can be set up to run only at night.
  244.       - Easily configurable, and portable to Sys V with a little work.
  245.     Disadvantages:
  246.       - All items in archive must be text, and are sent out as-is.  No
  247.         packaging options at all.
  248.       - Written in sh, may be a heavy system load (when running).
  249. Comments:    (Chris Siebenmann <cks@hawkwind.utcs.toronto.edu>)
  250.     We use the DECWRL server for the CA*NET info server; I picked
  251.     it over the other ones (primarily the Clarkson one) because it
  252.     was sufficiently small and clear that I could read all the
  253.     shell scripts and be pretty confidant that it had no surprises
  254.     and I understood what was going on. One could probably run it
  255.     out of a .forward file with some work writing at-based
  256.     frontends, but it prefers to be installed and run with cron
  257.     and an alias.
  258.  
  259. Name:        deliver
  260. Author:        Chip Salzenberg <chip@tct.com>
  261. Latest known version: 2.1, patchlevel 10
  262. How to get it:    From the comp.sources.reviewed archives.
  263. Implementation language: C
  264. Comments:
  265.     This isn't a full-fledged archive server, it's just a
  266.     program to reroute incoming mail.  Which isn't to say that it
  267.     can't be used to write an archive server....
  268. Comments:    (Brian.Onn@Canada.Sun.COM)
  269.     I've written our mail based archive server entirely in Deliver
  270.     shell scripts.  It's not as full featured as the other ones,
  271.     but it can easily be expanded to become that.  The beauty of
  272.     deliver is that it is entirely shell script based.
  273. Comments:    (Daniel Simmons <simmdan@kenya.isu.edu>)
  274.     The real beauty of deliver is that it is an extension allowing
  275.     you to implement mail handling in ANY language: shell scripts,
  276.     perl, C, awk... haskell if you want and can make it understand
  277.     environment variables and read/write to stdin/stdout (I don't
  278.     know haskell well enough to know if this is possible).
  279.  
  280.     I have written a very successful mail processing system which
  281.     installs data files in our local Campus Wide Information
  282.     System using a single (and fairly short) perl script in
  283.     conjunction with deliver.
  284.  
  285.     One other comment is that deliver is very comparable to
  286.     procmail but much cleaner/simpler.
  287.  
  288. Name:        ftpmail
  289. Author:        Lee McLoughlin <lmjm@doc.ic.ac.uk>
  290. Latest known version: 1.19
  291. How to get it:    src.doc.ic.ac.uk:/packages/ftpmail/ftpmail.shar
  292. Implementation language: perl
  293. Supported platforms: SunOS, HP/UX,  AIX (RS 6000), BSD 4.3, System 5.4
  294. Comments:
  295.     - Can use both mail and sendmail to send reponses.
  296.     - With sendmail can also return MIME multipart responses.
  297.     - Supports mime, uuencode, atob, user selectable splitting.
  298.     - Built in logging.
  299.     - Very easy to install.
  300.     - Command compatible with ftpmail server at Decwrl.
  301.  
  302. Name:        KISS
  303. Author:        T. William Wells <bill@twwells.com>
  304. Latest known version: 1.0
  305. How to get it:    - Get "kiss.shar" from grasp1.
  306.         - Get "misc/kiss.shar" from JASON-ARCHIVE (slightly modified).
  307.         - hydra.helsinki.fi:/pub/archives/alt.sources/kiss-server_bill
  308. Implementation language: bourne shell
  309. Comments:    (Dave Shaver <shaver@convex.com>)
  310.     - Simple.  8-)
  311.     - One shell script, plus a user-supplied program
  312.     - No batching, quotas, or scheduling.
  313.     - 5 user commands: help, index, send, path, quit
  314.     - Good install docs
  315.  
  316. Name:        ListProcessor
  317. Author:        Anastasios C. Kotsikonas (tasos@cs.bu.edu)
  318. Latest known version: 6.0c
  319. How to get it:    - cs.bu.edu[128.197.2.1|128.197.10.1]:/pub/listserv/*
  320.         - all of its mirrors (ftp.uu.net:/pub/networking/mail/listserv
  321.           for example).
  322.         - Via email to listproc@avs.com with the request:
  323.           "get listproc listproc6.0c.sh".
  324. Implementation language: C, plus some UNIX-style shell scripts.
  325. Supported platforms: UNIX, presumably.
  326. Comments:    (from the author)
  327.     This is a system that implements various mailing lists with
  328.     one list manager. It is automated, and obliterates the need
  329.     for user intervention and maintenance of multiple aliases of
  330.     the form "list, list-owner, list-request", etc. There is
  331.     support provided for public and private hierarchical archives,
  332.     moderated and non-moderated lists, peer lists, peer servers,
  333.     private lists, address aliasing, news connec- tions and
  334.     gateways, mail queueing, digests, list ownership, owner
  335.     preferences, crash recovery, batch processing, confi- gurable
  336.     headers, regular expressions, archive searching, and live user
  337.     connections via TCP/IP.
  338.  
  339. Name:        Logix
  340. Author:        Jan-Piet Mens
  341. Latest known version: 1.01
  342. How to get it: Get the posting entitled "Mail-Server Part 01/01" from
  343.     the alt.sources archives.  An improved version (Bill Silvert's
  344.     -- see his comments below) is available via anonymous ftp from
  345.     /dfo/net/mail-servers/mail-server.tar.Z on biome.bio.ns.ca.
  346. Implementation language: C
  347. Comments:    (Bill Silvert <silvert@biome.bio.ns.ca>)
  348.     Changes I have made include support for optional (as opposed
  349.     to compulsary) uuencoding using the Dumas uuencode, which
  350.     makes it possible to run uudecode (the Dumas version) on a
  351.     complete multi-part mail file without editing it first, and
  352.     improved messages.
  353.  
  354. Name:        MReply
  355. Author:        Tor Slettnes <tor@netcom.com>
  356. Maintainer:    Same
  357. Latest known version: 0.27
  358. How to get it:    - netcom.com:/pub/tor/mreply/mreply027.taz
  359.         - e-mail to tor@netcom.com.
  360. Implementation language: C (gcc)
  361. Supported platforms: Unix. Developed under SunOS 4.1.3.
  362. Comments:    (from the author)
  363.     - Mailing list AND file server in one.  Commands available:
  364.       JOIN/SUBSCRIBE, LEAVE/UNSUBSCRIBE, REVIEW, SEND, HELP.
  365.     - List options are: MANUAL vs. AUTOMATIC; CONCEAL vs. REVEAL
  366.     - File packet options are: PLAIN vs ENCODED.
  367.     - Built-in uuencode, shell archive generator, splitmail.
  368.     - Simple. Small. Source is < 30k; Typical config.
  369.       executable file about 10k.
  370.     - Sample configuration file w/lots of comments included.
  371.     - Can be installed w/o root access; invoked via .forward
  372.       mechanism (preferably via a preprocessor like "procmail"
  373.       or ELM's "filter").
  374.     - User definable mail headers (e.g. for support of MIME).
  375.     - Personalize replies by including the mailer's first name.
  376.     - Clever logging of requests.
  377.     - Requires 'sendmail' or another mailer.
  378.     - Free. Please notify me if you make changes/enhancments.
  379.  
  380.     For a demo, send an empty e-mail to notgnu-request@netcom.com.
  381.  
  382. Name:        MailServ
  383. Author:        Dave DeBry <debry@peruvian.cs.utah.edu>
  384. Latest known version: 1.4
  385. How to get it:    Get the posting entitled "MailServ 1.4" from the
  386.         alt.sources archives.
  387. Implementation language: C
  388. Comments:    (from the author)
  389.     - allows for as many users as you want per list,
  390.     - users can be mailed to "quietly" (ie: their name won't be
  391.       found anywhere in the mailing... good for nosy sysadmins at
  392.       other sites),
  393.     - has a request server so users can get any files you make
  394.       available for them,
  395.     - handles subscribes and unsubscribes without bothering you,
  396.     - can archive off reflector mailing list posts,
  397.     - can announce to all list readers when someone subscribes or
  398.       unsubscribes,
  399.     - can be set to let people request a list of readers,
  400.     - does all the digest handling work for you,
  401.     - can upload (via ftp) each days digest to a given site for
  402.       archiving,
  403.     - can backup the userlist to a different disk/area/whatever,
  404.     - can post a FAQ to USENET periodically,
  405.     - announces when a message has been taken from USENET, so
  406.       people don't get that horrible deja vu feeling while reading
  407.       their mail,
  408.     - sends you a log of all the day's activities every night,
  409.     - lets you toggle all of these things for complete
  410.       customization,
  411.     - and much, much more!  (I should be an announcer for those
  412.       Remco ads, I know it.)
  413.  
  414.     MailServ isn't for the weak at heart.  It's not pretty, and
  415.     I'm releasing it to the net because several people have asked
  416.     for copies, and I'd like to know what changes are made to it.
  417.     If you don't know much about UNIX or mail, I wouldn't suggest
  418.     using MailServ until it gets a little bit nicer.
  419.  
  420. Name:        Majordomo
  421. Author:        D. Brent Chapman <brent@GreatCircle.COM>
  422. Maintainer:    Same
  423. Latest known version: 1.54
  424. How to get it:    FTP.GreatCircle.COM:/pub/majordomo/*
  425. Implementation language: Perl and some C
  426. Supported platforms: UNIX
  427. Comments:    (from the author)
  428.     Majordomo is more of a mailing-list manager than an archive
  429.     server.  It has the concept of an "owner" for each list.  The
  430.     owner of a given list approves certain user "subscribe" and
  431.     "unsubscribe" commands (the ones that majordomo doesn't
  432.     automatically approve; for instance, if someone tries to
  433.     unsubscribe something other than their own email address from
  434.     a list, majordomo asks for approval).  Most list maintenance
  435.     is done for the owner by majordomo, and the rest can be done
  436.     by the owner using emailed commands to majordomo; the owner
  437.     doesn't need an account on the machine majordomo runs on.
  438.  
  439. Name:        NETLIB
  440. Author:        Jack J. Dongarra, Eric Grosse
  441. How to get it:    Get "netlib from misc" from NETLIB.
  442. Implementation language: C
  443. Comments:    (Dave Shaver <shaver@convex.com>)
  444.     - User-level docs a bit rough.    Assumes user is quite mail
  445.       savvy.  (Not a fair assumption in my case.)
  446.     - Catches "pigs" effectively, but no queuing system for
  447.       requests.
  448.     - Notices attempted security violations using magic shell
  449.       characters
  450.     - Install docs adequate, but not outstanding
  451.     - Hard to install since site-specific stuff not centralized
  452.       in a config file.
  453.     - Has almost no interal documentation (i.e. comments)
  454.     - Eclectic mix of shell scripts and C programs
  455.     - Some sections of code very specific to serving libs.    Does
  456.       not generalize well to ASCII files.
  457. Comments:    Tom Fitzgerald <fitz@wang.com>
  458.     Advantages:
  459.       - Arbitrary directories can be made part of archives, archives
  460.         don't have to all be under a single directory tree.
  461.       - Written in C, probably imposes the least system load.
  462.       - Reasonably portable and configurable.
  463.     Disadvantages:
  464.       - Really complicated, with inadequate documentation
  465.       - No queuing or load-balancing.  All requested items are sent
  466.         out immediately regardless of system load.
  467.       - Poorest at figuring out return addresses.
  468.       - All items in archive are sent out as-is.No packaging options.
  469.         (They can be binary, they will be sent out uuencoded).
  470.  
  471. Name:        procmail
  472. Author:        Stephen R. van den Berg <berg@pool.informatik.rwth-aachen.de>
  473. Latest known version: 2.91
  474. How to get it:    - Get "procmail" from volume 38 of comp.sources.misc
  475.     archives.
  476.         - ftp.informatik.rwth-aachen.de:/pub/unix/procmail.tar.zip
  477. Implementation language: C, plus some UNIX-style shell scripts.
  478. Supported platforms: generic UNIX (or any posix compliant OS)
  479. Comments:
  480.     Procmail is a program to parse incoming mail and sort/invoke other
  481.     programs based on the results, it can be used as a very reliable
  482.     frontend to some of the archive servers mentioned here.
  483.     It includes a utility program called formail, which is particularly
  484.     intelligent in figuring out return addresses and generating
  485.     auto-reply headers.
  486. Comments:    (from the author)
  487.     Included is an extensive mailinglist/archive server package (based
  488.     upon procmail/formail).  Regarding the archive server part:
  489.     Advantages:
  490.       - Easy to install.
  491.       - Straightforward to operate (one tree, symbolic links allowed).
  492.       - Numerous others :-), but you'll have to get the FEATURES file
  493.         from the package.
  494.     Disadvantages:
  495.       - Doesn't do special handling for binary files.
  496.       - Doesn't autosplit large files.
  497.       - Partly dependent on sendmail, though sufficiently compatible
  498.         mailers will do.
  499.       - No load balancing or queueing, relying on sendmail for that.
  500.  
  501. Name:        qdms
  502. Author:        Lars Magnusson <lmn@z.amu.se>
  503. Latest known version: 1.0
  504. How to get it: (1) Get "qdms - a simple mailserver for cramped disks."
  505.     from the alt.sources archives.  (2) Get a (possibly more
  506.     up-to-date) version from mailserver@z.amu.se.
  507. Implementation language: Bourne shell, requires shell functions
  508. Comments:
  509.     Looks like it has some sort of access control and blacklisting.
  510.     I Don't know what else.
  511.  
  512. Name:        RNALIB
  513. Author:        Paolo Ventafridda <venta@otello.sublink.org>
  514. Author:        Marco Lorenzini <marlor@gear.sublink.org>
  515. Latest known version: 2.2 beta-3
  516. Implementation language: bourne shell
  517. How to get it: (1) Get "rnalib2" from volume 15 of comp.sources.misc
  518.     archives.  (2) Get "RNALIB 2.2 beta" and "upgrade to beta-3"
  519.     from alt.sources archive on valhalla.ee.rochester.edu.
  520. Comments:
  521.     - Completely implemented in one bourne shell script plus
  522.       several data files.
  523.     - Allows libraries to be all over the filesystem hiearchy
  524.       (i.e. not in fixed data directory).
  525.     - Understands a variety of packing formats, and detects binary
  526.       file automatically (and uuencodes them).
  527.     - Requires bourne shell with support for functions.
  528.     - Very poor address parsing.
  529.     - No queueing.
  530.     - Has "blacklists" to prevent people from transferring and
  531.       "whitelists" to allow specific people to tell the server to
  532.       deliver to third parties.
  533.     - Detects "hogs" and imposes maximum credit limits.
  534.  
  535. Name:        Relcom
  536. Author:        vak@kiae.su (Serge Vakulenko)
  537. Maintainer:    Same
  538. Latest known version: 1.2
  539. How to get it:    Send a message to mailserv@kiae.su with
  540.         "get relcom/unix/ms12.tar.Z" in the body.
  541. Implementation language: C
  542.  
  543. Name:        The ServiceMail Toolkit, by Enterprise Integration Technologies
  544. Author:        Jay C. Weber <weber@eitech.com>, et al.
  545. Maintainer:    servicemail-help@eitech.com
  546. Latest known version: v2.0 5-10-93
  547. How to get it:    eitech.com:svcmail-2.0.tar.Z
  548. Implementation language(s): C, Tcl, make
  549. Supported platforms:  SunOS, Ultrix, (probably anything that supports Tcl)
  550. Comments:    (Bob Bagwill <bagwill@swe.ncsl.nist.gov>)
  551.     - Easy to install (using default installation configuration).
  552.     - Multimedia Email SHell (MESH) uses MIME message formats.
  553.     - Services are implemented in Tcl.
  554.     - Includes subset of listserv functions.
  555.     - Documentation is skimpy.
  556. Comments:    (Jay Weber <weber@eitech.com>)
  557.         - Documentation is better in 2.0
  558.         - Includes support for queueing, logging
  559.  
  560. Name:        Squirrel Mail Server
  561. Author:        Johan Vromans <jv@NL.net>
  562. Version:    3.1B
  563. How to get it:  Send a mail message to <mail-server@NL.net> with 
  564.         contents
  565.             begin
  566.             send mail-server
  567.             end
  568. Implementation language: perl
  569. Description:    (from the author)
  570.     The Squirrel Mail Server is a mail response program. You can
  571.     send email to it, and it will try to react sensible to your
  572.     message. 
  573.  
  574.     Main purpose of the mail server is to obtain files from a
  575.     local archive or FTP server, but other functions can be added
  576.     easily.
  577.  
  578.     The Squirrel Mail Server Software is distributed under the
  579.     terms of the GNU Public Licence.
  580.  
  581.     New and improved features in version 3.1:
  582.  
  583.       - Transparent (anonymous) FTP interface. You can fetch files
  584.         from remote FTP servers. Files retrieved are cached
  585.         locally, so subsequent requests can be honoured from the
  586.         cache.
  587.  
  588.       - Delivery can take place via email or uucp or both.
  589.         Delivery via UUCP can be made preferred.
  590.         FTP requests can be restricted to UUCP delivery.
  591.  
  592.       - Files can be automatically compressed, and directories can
  593.         be automatically packed using one of several common
  594.         methods (e.g. zip, zoo or compressed tar).
  595.  
  596.       - Multiple servers can be installed using the same software.
  597.  
  598.       - The server can be used interactively, e.g. from a
  599.         terminal, or via telnet/inetd.
  600.  
  601.       - Command parsing and execution is table driven, so it is
  602.         very easy to extend the mail server functions.
  603.  
  604.       - Rewritten and enhanced user documentation and
  605.         installation docs. Also available in nicely formatted
  606.         (PostScript) format.
  607.  
  608.     A brief survey of old and new features:
  609.  
  610.       - All written in perl, hence portable and easily
  611.         maintainable.  Code is readable; useful, plentiful
  612.         comments. Very extentable and easily modified.
  613.       - Easy to use and to install. Over 2000 lines of
  614.         documentation. 
  615.       - Good at letting person making request know what happened.
  616.         Good "help" reply.
  617.       - Archives can be split over a number of directories or file
  618.         systems.
  619.       - Requests are queued and processed by a separate daemon
  620.         process (e.g. from cron). This cuts down on the system
  621.         load. Moreover, you can control when the queue is being
  622.         run.
  623.       - Requests can be honoured `as is' (name the file and you'll
  624.         get it), but the server can also perform directory
  625.         searches and index file lookup.  You need GNU find and
  626.         locate for the index lookup feature.
  627.       - While looking for files, the server knows about commonly
  628.         handled filenames (e.g. ".tar.Z" in "foo.tar.Z") and
  629.         pseudo-standard version numbering (e.g. "gcc-2.1.tar.Z").
  630.         It is quite well possible that a simple request for
  631.         "emacs" will actually transmit the file
  632.         "gnu/emacs-18.58/dist/emacs-18.58.tar.Z".
  633.       - Requests can be encoded using a number of encoding
  634.         schemes, e.g.  uuencode, xxencode, Dumas' uue and btoa.
  635.       - Requests that are too large to send in one piece are
  636.         automatically split and transferred in parts. The server
  637.         provides a smart unpacking program on request,
  638.       - Parts of requests can be re-transmitted in case of
  639.         failure.
  640.       - Requests can designate a directory. In this case the whole
  641.         directory tree is packed using some popular packing
  642.         programs (compressed tar, zoo or zip).
  643.       - Requests can be sent by email, or via uucp.
  644.       - The server can be asked to return a list of archive
  645.         entries that match a given request, thus obsoleting the
  646.         need to transfer huge "ls-lR" type index files to find out
  647.         whatsitcalled.
  648.       - All transfers are logged. Maintenance procedures
  649.         include a reporting tool.
  650.  
  651.     Probable future directions:
  652.  
  653.       - Automatic (and transparent) downloading of unknown archive
  654.         entries from other archive servers.
  655.       - Archive lookup by keyword.
  656.       - Notifier services (you'll be notified if archive entries
  657.         are added).
  658.       - Remote maintenance of the archives.
  659.  
  660.     Requirements:
  661.  
  662.       - Perl 4.0 patchlevel 36 or later.
  663.       - GNU find 3.6 or later (only if you want to exploit the
  664.         index features).
  665.       - A decent mail system that can deliver mail to a process
  666.         (sendmail, smail3, or smail2.5 w/ mods).
  667.  
  668.     Mailing list:
  669.  
  670.       A mailing list exists for sites that are running the
  671.       Squirrel Mail Server software. You can subscribe by sending
  672.       a mail to <squirrel-server-request@NL.net>.
  673.  
  674.  
  675. 2.0    Archivers, what they archive, how to download
  676.  
  677.               Archive Site Instructions
  678.               -------------------------
  679.  
  680. CLARKSON: Send mail to "archive-server@sun.soe.clarkson.edu" with
  681.     "send <what you want>" as the text of the message, e.g. "send
  682.     archive-server".  If you want it to be archived as a shar
  683.     file, then add a line saying "archiver shar" before the "send"
  684.     line.  You can also use "archiver tar".  If you don't specify
  685.     an archiver, then the files in the request will be separated
  686.     by "--- cut here ---" lines and you'll have to extract them by
  687.     hand or write some sort of script to do it.
  688.  
  689. grasp1: Ftp to grasp1.univ-lyon1.fr and look in
  690.     pub/unix/mail/mail-servers, or use the FTP-by-mail server at
  691.     ftpmail@grasp1.univ-lyon1.fr, or use an FTP-by-mail server
  692.     closer to you if there is one.
  693.  
  694. JASON-ARCHIVE: Send mail to "penneyj@slc.com" with a subject line
  695.     containing the string "jason-archive-request" and a body
  696.     containing "send <what you want>", e.g. "send misc/kiss.shar".
  697.     If you want multiple files, you can specify multiple requests
  698.     on separate lines of the file.
  699.  
  700. NETLIB: Send mail to "netlib@research.att.com" with "send
  701.     <what you want>", e.g. "send netlib from misc", as the text of
  702.     the message.
  703.  
  704. UTRECHT: Anonymous ftp to ftp.cs.ruu.nl and look in the directory
  705.     /pub, or send mail to "mail-server@cs.ruu.nl" with the lines:
  706.         begin
  707.         send <filename>
  708.         end
  709.     You replace "<filename>" with the file you want to retrieve,
  710.     e.g. "send UNIX/mailserver.tar.Z".
  711.  
  712. 3.0    History and Contributors
  713.  
  714.     This FAQ was originally maintained by Jonathan I. Kamens
  715.     (jik@security.ov.com). He's now in the need of a subsitute, so
  716.     I'm taking care of it. Needless to say, all the work herein
  717.     is Jonathan's.
  718.  
  719.     The following people, in chronological order, provided comments
  720.     about and corrections to this posting:
  721.  
  722.     - John Bazik <jsb@cs.brown.edu>
  723.     - Stephen R. van den Berg <berg@pool.informatik.rwth-aachen.de>
  724.     - Warren Burstein <warren@itex.jct.ac.il>,
  725.     - Nigel Metheringham <nigelm@ohm.york.ac.uk>
  726.     - Mike Northam <mbn@fpssun.fps.com>
  727.     - Chip Salzenberg <chip@tct.com>
  728.     - Serge Vakulenko <vak@kiae.su>
  729.     - jv@NL.net (Johan Vromans)
  730.       Tue, 1 Feb 1994 15:26:54 +0100 about Squirrel Mail Server
  731.  
  732. ----------------------
  733. *** END of Mail Archive Servers FAQ *** This file has not been truncated
  734. -- 
  735. Piero Serini                                 Computer Science Dept. 
  736. <serini@ghost.dsi.unimi.it>          Univ. Statale - Milano - ITALY
  737.  
  738.